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FOREWORD 


Studies by NASA contractors and others over the last fifteen years 
have emphasized the potential benefits, including costs, of 
selected manned operations. A satellite servicing study in the 
late sixties summarized the problem; 

"Since so many aspects of space are dynamic, it. should 
be clear that it would be foolhardy to expect that 
satellites could be manufactured so that they would 
never deteriorate, have a limitless useful life, be 
absolutely reliable, and be inexpensive and standard- 
ized instead of complex. ..." 

"One possibility is to devote more of society's limited 
resources to greater pre-orbit efforts of design, manu- 
facture, test, and launch. However, the incremental 
improvement in the listed problem area . . . would 
probably be very small relative to the effort involved." 

"An alternate way to improve the present situation 
would be to . . . launch the satellite, let it malfunc- 
tion, run-down, deteriorate, or become partially obso- 
lete, then take corrective actions while it is in orbit." 

"This technique has the tremendous advantage of pin 
pointing a problem for that specific satellite thereby 
creating a high probability that a specific relative 
improvement can be made . . . this improvement can 
usually be accomplished in a short time and with less 
expense relative to any pre-orbit effort." 

"The obvious superiority of the in-orbit correction 
method led space program planners to suggest the 
creation of a space vehicle that would be designed 
to perform the necessary corrections . " 

The Space Transportation System (STS) provides the basic tools 
required for an on-orbit servicing and maintenance capability. 

With man onboard the STS , he represents an STS subsystem that 
can be used to accomplish planned payload mission objectives, as 
well as contingency service and maintenance functions. 
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INTEGRATING THE MANNED INTERFACE 


The manned interface is defined as the equipment and systems 
manipulated or used directly by man in performance of a payload 
function. Previous manned space flight experience has shown that 
the effective use of man's capabilities requires careful atten- 
tion to integration of the manned interface. A variety of tech- 
niques have been used to facilitate the integration process. 

These techniques have included desk-top modeling and analysis; task 
simulations using part-task and full-scale models of task hard- 
ware; and space environment simulation using thermal vacuum and 
water immersion facilities. One of the techniques used early in 
the integration process is the "operations scenario." Develop- 
ment of the operations scenario enhances the analysis of manned 
operations . It is presented as an initial link between the 
hardware as conceptualized and the design required for successful 
manned operations . 

An "operations scenario" may be defined as the end-to-end sequencing 
of all subtasks required to perform an operation. The development 
of an operations scenario involves the identification of all 
hardware and software systems, personnel, and other items re- 
quired for each subtask to be accomplished. A sample format for 
developing an operations scenario is illustrated in Figure 1.- 
This particular format was prepared for development of an Extra- 
vehicular Activity (EVA) function, but it could be modified and 
used for development of aft crew station or other Intravehicular 
Activity (IVA) functions. All items required for subtask per- 
formance are identified as operational support requirements. 

Other requirements should be added as needed to accomplish the 
subtasks. Development of the scenario begins with the identi- 
fication of a potential manned task. Potential manned tasks 
can be identified from an analysis of system functions. Initially, 
the task may be a general statement of some operation to be 
performed. The operation should be broken into the lowest mean- 
ingful subtasks. The sequence of tasks is determined by the ob- 
jective of the operation. Several iterations may be required to 
identify the lowest subtask and the most effective sequence. 

As the performance of each task is considered, all items required 
for performance are identified. For example, if a subtask iden- 
tified as "4.3 Power Switch - On" required performance from the 
aft crew station, the "perform 4.3" would be entered into the 
personnel column title "AFT C/S" (i.e., at Orbiter crew station). 

The location column identifies the position of the individual 
performing the particular subtasks. This data locates personnel 
during the performance of all subtasks , and it may be used to 
determine a more efficient subtask sequence. It may also be used 
to determine a more effective location of the subtasks. This 
column may also serve as a cue for documenting environmental 
requirements such as radiation protection, spacecraft attitude, or 
solar fliix limits. Other columns for environmental requirements 
may be added if they are relevant issues. 
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FIGURE 1 — Operation Scenario Development 
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The task hardware/software column identifies the hardware/soft- 
ware required for direct performance of the task. In the aft 
crew station example, a power control switch may be required. If 
a unique control panel for the switch is required, it would also 
be entered in this column. Software or wiring may also be re- 
quired to perform this subtask. The adjacent column identifies 
requirements for task support hardware/software. Support hardware 
facilitates the performance of the subtasks or contributes to 
maintaining the capability , to perform the subtask. Examples of 
this hardware include body restraints, stowage devices, and port- 
able lighting. Task performance requirements identify either per- 
formance limits or requirements for hardware/software. A per- 
formance limit on the rotation of a power control switch may be 
identified as "10 in- lbs." "Body restraint" in this column may 
identify the performance requirement for a handhold. The capabil- 
ity/technology status column may be used to qualify the perform- 
ance of any subtasks. (A "check mark" may be entered to indicate 
that there is no capability or technology concerns relative to the 
subtask performance) . The capability/technology status column 
may also be used to indicate that the subtask has been performed 
in the past or that a demonstration is required to verify its 
performance. The column could also identify a state-of-the-art 
technology concern or deficiency. The last column may be used 
to identify special requirements that may surface as a result 
of scenario development. The existence of off-the-shelf hardware 
is a note that could be entered. The column may also identify and 
track stowage requirements for loose equipment. 

Once the operations scenario has been developed, each subtask 
should be reviewed to estimate the time required for its comple- 
tion and this time should be entered in the time task coliamn. If 
the subtask performance time is unknown, personnel familiar with 
the task or task performance records may provide an estimate. In 
some cases, a subtask demonstration may be required to determine 
the performance time. Once the subtask's performance times have 
been estimated or determined, the accumulated total provides a 
preliminary timeline for the scenario. Development of the scenario 
may be repeated as new data on potential manned tasks, task hardware, 
or task support hardware becomes available. A refined operations 
scenario provides a source of data for reference prior to the 
availability of hardware for demonstration and evaluation. 

An analysis of the refined operations scenario will provide a 
source of preliminary data for program documentation, such as 
system design and performance requirements . The subtasks and time- 
line data will also provide an input into preliminary flight data 
file articles such as the flight plan and checklists. Preliminary 
training plans and training facility plans can be generated from 
the task data and the operational support requirements data. A 
sample matrix of operations scenario products referenced to pre- 
liminary program documents is shown in Figure 2 . A subtask opera- 
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tional support requirement, such as foot restraints, provides an 
input into the payload program's preliminary design and performance 
requirements document. This input may affect the payload's mech- 
anical systems requirements or the crew systems requirements 
depending upon the subdivisions of the requirements document. 

The operations scenario data can be used to generate concept 
demonstration and evaluation plans. Low-cost mockups or prototype 
hardware may be used to refine and revise the operations scenario 
or the requirements generated by scenario development. The data 
generated by development of one operations scenario may be used 
in concept evaluation and development and trade-off studies with 
an alternate approach or another potential manned task . 
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